Thanks — this is a clear question and good detail. I’ll address whether you can present the original inbound caller’s phone number as the caller ID on an outbound SIP call (CreateSIPParticipantRequest → Twilio Elastic SIP Trunk), explain why you’re seeing the 403 and CNAM behavior, and give practical recommendations you can use today. Short answer • You cannot present an arbitrary customer phone number on the PSTN leg through Twilio unless that number is verified/allowed on your Twilio account. Twilio will reject unverified caller IDs (403). • Injecting

P-Asserted-Identity

from LiveKit toward Twilio will not let you bypass Twilio’s validation for outbound PSTN calls. • The reliable options are: use a Twilio-verified number as the outbound caller ID and surface the real customer number in the call flow (display_name/CNAM where useful, in-call announcement, or internal SIP URI + header approach for VoIP-only destinations). Why you see the 403 and why CNAM is limited • Twilio rejects attempts to send an unverified phone number as the outbound caller ID (that causes the 403 "Caller ID is unauthorized"). This is carrier/anti-spoofing behavior — you can’t present arbitrary ANI on PSTN unless Twilio has authorized that number on your account. •

display_name

(CNAM) can be passed at the SIP level and may show up on VoIP phones and some PBXs, but mobile carriers and many mobile handsets typically show only the numeric caller ID and ignore CNAM. So CNAM alone won’t reliably show the customer number on supervisors’ mobile phones. About

P-Asserted-Identity

and

attributes_to_headers

•

attributes_to_headers

is not available for creating outbound SIP participants in a way that will override the PSTN caller ID on Twilio. That mapping is used for specific inbound flows and does not provide a general bypass for Twilio’s outbound caller ID rules. • Twilio does not accept arbitrary

P-Asserted-Identity

from an external SIP trunk as proof to set the ANI on the PSTN leg. Even if you add a

P-Asserted-Identity

header in the INVITE, Twilio will validate and enforce caller ID policies and will not allow unverified numbers to become the PSTN caller ID. Practical, recommended approaches 1) Use a Twilio-verified number as the outbound caller ID (recommended, compliant) • Set

sip_number

in CreateSIPParticipantRequest to a verified Twilio number you control. • This avoids 403s and is supported by carriers. • Improve recognition by setting

display_name

or

participant_name

to include the customer number (helps VoIP/PBX clients). 2) Surface the real customer number in the call itself • Have the AI agent or IVR speak: “You are being connected to a call from +1-555-123-4567” during the warm transfer briefing. • This is reliable across mobile and PSTN devices. 3) Use SIP URI + header pass-through for internal VoIP destinations (works only for VoIP/PBX, not mobile PSTN) • If the supervisor can be called via SIP URI (e.g.,

<sip:supervisor@your-pbx.exampl>e

), create the participant to that SIP URI and include headers such as

P-Asserted-Identity

or a custom

X-Original-Caller

. • Your PBX can read those headers and display the original caller number in the agent UI. • This approach will not affect PSTN calls to mobile phones — it only works for SIP endpoints that honor headers. 4) If you need true ANI passthrough to PSTN numbers • You must have the number verified on Twilio (or use a carrier/SBC arrangement that allows authenticated third-party ANI presentation). That typically means: ◦ Verifying the number with Twilio, or ◦ Using your own carrier connection/SBC with direct PSTN agreements that support authenticated third-party ANI (more complex and costly). Quick code notes (what to try now) • Set

sip_number

to your verified Twilio number when you call CreateSIPParticipantRequest. • Set

participant_name

or

display_name

to include

original_caller_number

so VoIP clients/PBXes see it. • Example fields to set (pseudo): 1. Outbound to PSTN supervisor (works universally) ◦ sip_call_to: supervisor_phone_number ◦ sip_number: your_verified_twilio_number ◦ participant_name: f"Customer: {original_caller_number}" 1. Outbound to a SIP URI (internal PBX) ◦ sip_call_to: "sip:supervisor@your-pbx.example" ◦ headers: { "P-Asserted-Identity": f"sip:{original_caller_number}@your-domain" , "X-Original-Caller": original_caller_number } ◦ (PBX must consume those headers) Which approach should you pick? • If supervisors are on mobile/PSTN: Use a verified Twilio number and announce the original caller inside the call. That is the only reliable option across carriers. • If supervisors are on an internal PBX/SIP client: Use SIP URI dialing and pass headers so the PBX can display the original number. If you’d like, I can help with: • A concrete example of the CreateSIPParticipantRequest payload you’re currently using so we can adapt it to use a verified

sip_number

and

participant_name

. • An example headers payload for SIP-URI-based dialing so your PBX can consume

P-Asserted-Identity

or

X-Original-Caller

. • Guidance on Twilio console trunk settings to ensure the trunk forwards the From header (where applicable). Which of those would be most helpful next — a PSTN-ready CreateSIPParticipantRequest example using a verified number, or a SIP-URI + headers example for internal VoIP destinations? Sources: How to do call transfers with Five9 | LiveKit | Preserve caller ID during SIP transfers with Twilio | LiveKit | Preserving Caller ID During SIP Transfers in LiveKit Agents